[00:14.200 --> 00:17.740]  Good morning, and welcome to the AppSec Village.
[00:17.740 --> 00:20.860]  I hope you were here for our first keynote speaker.
[00:20.860 --> 00:25.380]  Welcome to day one of AppSec Village, part of DEF CON 2020.
[00:25.540 --> 00:29.960]  I really wish we were all together in one big room like we were last year,
[00:29.960 --> 00:32.300]  but that's just not going to happen this year.
[00:32.300 --> 00:35.680]  So, in the meantime, thanks for tuning in.
[00:35.680 --> 00:38.560]  Thanks for watching along with us.
[00:39.420 --> 00:43.620]  I want to take the moment to introduce you to our next speaker.
[00:43.640 --> 00:49.700]  Our next presentation is going to be 2FA in 2020 and beyond by Kelly Robinson.
[00:49.700 --> 00:52.460]  Kelly works on the account security team at Twilio.
[00:52.460 --> 00:57.480]  Previously, she worked in a variety of API platforms and data engineering roles at startups.
[00:57.480 --> 01:02.300]  Her research focuses on authentication user experience and design tradeoffs
[01:02.300 --> 01:05.160]  for different risk profiles and 2FA channels.
[01:05.160 --> 01:07.480]  We all know how important 2FA is today.
[01:07.480 --> 01:09.680]  We all want to protect our accounts.
[01:09.760 --> 01:12.160]  And I'm looking forward to this talk. I hope you are too.
[01:12.160 --> 01:17.100]  So, please give a warm AppSec Village welcome to Kelly Robinson.
[01:18.360 --> 01:25.920]  Hey, everyone. I am coming to you today from Bravel,
[01:25.920 --> 01:30.360]  wherever you may be on this March 152nd.
[01:30.740 --> 01:35.140]  Hopefully, your day is going better than the person who has this password.
[01:35.380 --> 01:38.540]  But even though I trust everyone tuning into a DEF CON talk
[01:38.540 --> 01:44.220]  to have better password hygiene than something as simple as 1, 2, 3, 4, 5, 6,
[01:44.220 --> 01:49.180]  the fact is there's still a lot of folks out there with short, guessable passwords
[01:49.180 --> 01:52.940]  or people that are reusing passwords across multiple sites.
[01:54.380 --> 01:56.660]  And as much as we'd like to believe that we're better than this,
[01:56.660 --> 02:02.120]  the website haveibeenowned.com proves that simple passwords like 1, 2, 3, 4, 5, 6
[02:02.120 --> 02:04.200]  are still incredibly common.
[02:04.200 --> 02:08.880]  This password has been seen almost 24 million times across data breaches.
[02:09.200 --> 02:13.300]  And attackers can use this to do credential-stuffing attacks across the web.
[02:13.300 --> 02:17.340]  And it can basically allow them to hack into a lot of accounts
[02:17.340 --> 02:21.100]  and compromise a lot of credentials and ultimately make a lot of money
[02:21.100 --> 02:24.260]  off of unsuspecting individuals.
[02:24.340 --> 02:26.200]  And that's what we're here to discuss today,
[02:26.200 --> 02:30.820]  this reality where we are so owned that passwords are no longer enough,
[02:30.820 --> 02:36.280]  how other factors, second factors, in fact, can help us stay more secure,
[02:36.280 --> 02:39.140]  and how to evaluate the different options out there.
[02:39.920 --> 02:42.160]  So my name is Kelly Robinson.
[02:42.160 --> 02:45.480]  I have been working at Twilio for about three years.
[02:45.560 --> 02:48.920]  And I specifically work on Twilio's account security team,
[02:48.920 --> 02:52.520]  working with our products for things like Verify, Lookup,
[02:52.520 --> 02:55.860]  anything that has to do with phone verification, two-factor authentication,
[02:55.860 --> 02:58.760]  phone and email intelligence, things like that.
[02:58.760 --> 03:00.380]  And this team has evolved a lot.
[03:00.380 --> 03:04.780]  We acquired Authy about five years ago, and that was kind of the genesis of the team.
[03:05.700 --> 03:07.780]  So Authy is our free consumer application
[03:07.780 --> 03:11.760]  that was recently rendered to include the Twilio name about five years later.
[03:11.760 --> 03:15.960]  But we also have APIs for adding things like two-factor authentication
[03:15.960 --> 03:17.140]  into your applications.
[03:17.140 --> 03:21.060]  And I spend a good chunk of my time educating developers about security,
[03:21.060 --> 03:23.620]  especially when it comes to authentication itself.
[03:23.660 --> 03:26.820]  And so this talk is going to incorporate a lot of the things that I've learned
[03:26.820 --> 03:30.560]  in the last few years working with developers on a variety of challenges
[03:30.560 --> 03:34.640]  and our customers on their authentication challenges as well.
[03:36.120 --> 03:39.360]  And the failure of good authentication often results in
[03:39.360 --> 03:42.020]  what we call account takeover, or ATO.
[03:42.020 --> 03:44.220]  And this is why this is such a big problem, right?
[03:44.220 --> 03:47.480]  Like, if there wasn't anything of value on the other side of an account,
[03:47.480 --> 03:49.740]  we wouldn't be as concerned about this.
[03:49.740 --> 03:52.620]  But this is a $7 billion problem,
[03:52.620 --> 03:56.360]  so the industry is really incentivized to find a solution here.
[03:56.360 --> 03:59.560]  And from the 2020 Javelin Strategy and Research Study
[03:59.560 --> 04:01.920]  that just came out a few months ago,
[04:01.920 --> 04:04.500]  one of the things that they noted is that account takeover fraud
[04:04.500 --> 04:06.600]  is one of the hardest types of fraud to identify
[04:07.260 --> 04:10.960]  because there's so many channels, multi-channel account access,
[04:10.960 --> 04:14.580]  and the desire to reduce friction in the consumer experience.
[04:14.600 --> 04:17.340]  And so we're trying to make it easy for people to log in,
[04:17.340 --> 04:22.420]  but we also want to keep out the people that shouldn't have access to those accounts.
[04:22.420 --> 04:25.180]  And those can sometimes be conflicting goals.
[04:25.180 --> 04:28.680]  So how do we accomplish this, and how do we accomplish those goals?
[04:29.720 --> 04:34.500]  So protecting our accounts, we have these three types of factors that we'll talk about.
[04:34.520 --> 04:37.300]  You need to use a factor of authentication,
[04:37.300 --> 04:41.920]  and using any two of these means that you're using two-factor authentication.
[04:42.080 --> 04:44.000]  So there are three types of factors that we talk about.
[04:44.000 --> 04:46.540]  Something that you know, this could be like a password.
[04:46.600 --> 04:49.820]  Something that you have, this could be a key or a phone.
[04:49.820 --> 04:52.860]  And then something that you are, so this is something biometrics,
[04:52.860 --> 04:56.620]  like a fingerprint or a face ID or something like that.
[04:56.740 --> 04:59.040]  And all of the factors that we're going to be talking about today
[04:59.040 --> 05:02.660]  are channels that fall into this possession category.
[05:03.200 --> 05:06.740]  And I just kind of wanted to go over what the different pros and cons of
[05:07.280 --> 05:10.620]  a lot of these different common channels for two-factor authentication are,
[05:10.620 --> 05:15.740]  so we can think about why we would or would not enable some of these types of channels.
[05:15.740 --> 05:21.040]  And starting with second-factor authentication, using SMS 2FA codes.
[05:21.040 --> 05:24.840]  And so one of the big reasons that people still like SMS-based 2FA
[05:24.840 --> 05:27.740]  is that onboarding is so easy.
[05:27.740 --> 05:32.820]  So about 99% of Americans have a phone capable of receiving text messages.
[05:33.200 --> 05:36.120]  And that makes a big difference, right?
[05:36.120 --> 05:40.740]  Like if you can't get people to turn on 2FA or opt into 2FA,
[05:40.740 --> 05:45.620]  then you're not going to have any of the benefits of having the second factor offered to them.
[05:45.620 --> 05:49.680]  And because of this easy onboarding, because it's a familiar experience now,
[05:49.680 --> 05:53.100]  this is something that a lot of companies still like to offer,
[05:53.100 --> 05:56.900]  because it's offering that additional security without that additional friction.
[05:57.160 --> 06:02.380]  Unfortunately, as a lot of people know, SMS-based 2FA is not that secure.
[06:02.380 --> 06:07.700]  So one of the main reasons that we say this is because of something called SIM swapping.
[06:07.700 --> 06:11.400]  So this is where an attacker could use either social engineering or bribery
[06:11.400 --> 06:14.280]  to get my SIM card sent to you.
[06:14.280 --> 06:18.660]  And then you could basically take over control of my phone number.
[06:18.660 --> 06:23.680]  And so it's not device control, so SIM swapping allows you to take control of a phone number.
[06:24.020 --> 06:28.460]  And that can give you a lot of access to things that are being sent to me,
[06:28.460 --> 06:30.560]  like two-factor authentication codes.
[06:31.960 --> 06:36.700]  So SMS one-time passwords are really convenient, but they are an insecure channel.
[06:37.460 --> 06:42.080]  The next thing that I wanted to talk about was TOTP, or time-based one-time passwords.
[06:42.080 --> 06:45.140]  And this is a way to generate tokens based on an algorithm.
[06:45.140 --> 06:48.660]  So the inputs here are a secret key and your system time.
[06:48.660 --> 06:52.580]  And those get put through a one-way function that pops out the truncated token.
[06:53.120 --> 06:56.940]  So this is what Google Authenticator, Authy, apps like that use.
[06:56.940 --> 06:58.800]  It's an open standard.
[06:59.120 --> 07:03.340]  And symmetric key cryptography offers increased security compared to SMS.
[07:03.480 --> 07:07.820]  But if somebody gets access to that shared secret, then the method is easy to compromise.
[07:07.820 --> 07:10.540]  And you might be saying, well, don't leak that secret.
[07:10.560 --> 07:14.900]  But one of the ways that we'd share that secret is by scanning a QR code.
[07:14.900 --> 07:17.400]  There's ways that that QR code can get leaked.
[07:17.400 --> 07:27.140]  At a previous job, we used to keep a copy of a QR code for TOTP in the shared one-password file that we used for engineering onboarding.
[07:27.140 --> 07:31.560]  Because we wanted to enable 2FA, but we needed multiple people to have access to it.
[07:31.560 --> 07:35.980]  So that's one example of how a TOTP secret could get leaked.
[07:36.240 --> 07:38.760]  It offers also some distinct advantages.
[07:38.760 --> 07:41.480]  Like I mentioned, it's an open standard, which is pretty cool.
[07:41.480 --> 07:44.800]  So you can use the app of your choice to do this.
[07:44.800 --> 07:50.240]  And also, because the inputs are offline inputs, this method is also available offline.
[07:50.240 --> 08:01.660]  So not that anybody's doing a ton of traveling right now, but this is really useful for people when they're on a plane or in a foreign country where they might not have good cell service or cell service of any kind.
[08:01.840 --> 08:04.580]  But unfortunately, this does require an app download.
[08:04.860 --> 08:11.820]  And so this is something that you want to keep in mind, because that's going to add additional friction to get people to sign up for this method.
[08:11.820 --> 08:14.880]  And then I do want to mention the expiration user experience.
[08:14.880 --> 08:26.920]  Because in a study on the usability of different factors, researchers found that two-thirds of participants using TOTP via Google Authenticator had problems entering the six-digit code before it timed out.
[08:26.920 --> 08:30.900]  And so that could be a problem, depending on the types of users that might be using this.
[08:30.900 --> 08:35.580]  That expiration logic helps keep it secure, but it also could make it harder to use.
[08:36.340 --> 08:38.220]  Overall, this is a pretty good option.
[08:38.220 --> 08:43.620]  We see a lot of security-conscious companies adding TOTP as a 2FA option.
[08:43.620 --> 08:53.300]  And it's a really good next step of a way to add an open-source, open-standard option on top of SMSVite 2FA if you want to add additional security.
[08:54.780 --> 08:58.040]  So I also wanted to talk about pre-generated codes.
[08:58.040 --> 09:02.240]  And so these are something called, you know, like we might know these as backup codes.
[09:02.240 --> 09:05.360]  You don't see these used a lot for ongoing login.
[09:05.860 --> 09:11.080]  But I wanted to mention these because a study that I'm going to reference talks about using pre-generated codes.
[09:11.080 --> 09:13.160]  And then the benefit is that these are really easy to use.
[09:13.160 --> 09:17.800]  These are basically like passcodes or passwords that are generated for you.
[09:17.820 --> 09:19.940]  So they're less likely to be reused.
[09:20.280 --> 09:22.800]  They're more likely to be more secure.
[09:23.060 --> 09:26.160]  They're not going to be 1, 2, 3, 4, 5, 6.
[09:26.160 --> 09:32.860]  But, you know, because of that, 25% of participants in the study noted that these pre-generated codes didn't really feel secure, though.
[09:32.860 --> 09:35.080]  Because they're just kind of written down on a piece of paper.
[09:35.080 --> 09:45.720]  And the other problem with this is if you've ever been somebody that has been asked to store backup codes or implemented a system that has this kind of system, like, how do you store those?
[09:45.720 --> 09:49.220]  A lot of companies don't give you real guidance on that.
[09:49.640 --> 09:52.540]  And this is something that might not just, like, feel that secure.
[09:52.620 --> 09:55.700]  So this is something that I think is an option for backups.
[09:55.700 --> 09:59.380]  But the ongoing usability of it might not be super practical.
[10:00.760 --> 10:02.980]  Finally, I want to talk about push authentication.
[10:02.980 --> 10:06.660]  And this was really popularized by apps like Dual Authenticator.
[10:06.660 --> 10:09.540]  And users love this because it's so low friction.
[10:09.540 --> 10:13.460]  So you can approve or deny a login request directly from your smartwatch.
[10:13.500 --> 10:17.400]  And it uses asymmetric key cryptography, which means that you have two keys.
[10:17.400 --> 10:21.100]  The private key is only ever going to be stored on your device.
[10:21.100 --> 10:29.740]  And so that really keeps you more secure and prevents you from leaking a shared secret like you might be able to with TOTP.
[10:29.740 --> 10:34.900]  And this is the only form of 2FA that adds the option to explicitly deny a login.
[10:35.120 --> 10:40.700]  But unfortunately, it's so low friction that you could easily approve an authorization request just to get rid of it.
[10:40.900 --> 10:45.580]  And so if somebody is attempting to attack your accounts in the middle of the night,
[10:45.580 --> 10:50.500]  you might be able to unintentionally approve a request just to make it go away.
[10:50.800 --> 10:52.800]  And this also is a proprietary solution.
[10:52.800 --> 10:55.080]  So it's going to require a special app.
[10:55.080 --> 10:56.740]  So you could do this with something like Authy.
[10:56.740 --> 10:58.180]  You could do this with something like Duo.
[10:58.180 --> 11:01.080]  And you could also bake this into your own application.
[11:01.360 --> 11:06.940]  But like with TOTP, getting users to download another app is always going to be a challenge.
[11:07.160 --> 11:14.680]  I think the way that we'll see this become more common is with companies that have a lot of mobile users that already have their apps,
[11:14.680 --> 11:18.120]  baking this into the existing apps that are already on their phone.
[11:18.120 --> 11:20.580]  So you've seen this with something like Google Prompt.
[11:20.580 --> 11:26.160]  If you enable Google Prompt and try to log in on the browser, what Google will do is say,
[11:26.160 --> 11:30.620]  hey, check your phone, open up any Google app on your phone, and it will pop up this type of,
[11:30.620 --> 11:35.700]  is this you trying to log in message without requiring that the user downloads an additional app.
[11:35.700 --> 11:43.780]  And so that is one of the ways that you can kind of get around that user experience hurdle of having users opt into a more secure solution.
[11:44.380 --> 11:47.140]  This seems great. It's really cryptographically secure.
[11:47.140 --> 11:54.360]  But I think the onboarding logic is going to be something that we're going to struggle with for the next few years
[11:54.360 --> 11:59.120]  until this becomes more common. And there's always this problem that it might be too convenient.
[12:00.120 --> 12:02.400]  And then lastly, we'll talk about WebAuthn.
[12:02.400 --> 12:04.380]  And this is the new hotness for good reason.
[12:04.380 --> 12:09.780]  It offers a really high level of security with asymmetric key cryptography like push authentication.
[12:10.120 --> 12:13.020]  So the private key is only ever going to be stored on the device.
[12:13.020 --> 12:16.180]  But it's also an open standard like TOTP.
[12:16.220 --> 12:22.660]  So the biggest drawbacks with WebAuthn right now is that it's still relatively new and setup can be a little bit clunky.
[12:22.660 --> 12:28.320]  Some of the new devices are starting to bake this into the actual device itself.
[12:28.420 --> 12:33.900]  And so Android phones can now be used as a WebAuthn authenticator for Google products.
[12:33.900 --> 12:37.700]  But this is not something that you're seeing as widespread yet.
[12:37.700 --> 12:42.200]  Hopefully this will be something that will be rolling out more widespread with devices that we already have.
[12:42.200 --> 12:51.320]  But for something kind of third party that you can use to do this like a YubiKey, you need that additional authenticator right now to do this in a lot of places.
[12:52.220 --> 12:55.040]  An authenticator that's compatible with the standard.
[12:55.040 --> 12:58.440]  And, you know, YubiKeys, Titan keys, they're not exactly cheap.
[12:58.440 --> 13:03.380]  And you can't also reasonably expect that every user of your application will have one.
[13:03.380 --> 13:11.520]  So until something like this becomes a standard available on every mobile phone, it's going to be harder to implement this across the board.
[13:12.100 --> 13:20.240]  So like I said, as more devices like we already have, like our phones and our laptops, start to adopt the standard and become those kind of compatible authenticators,
[13:20.240 --> 13:22.380]  we will see an uptake in this factor.
[13:22.380 --> 13:26.020]  And I think this is where you can kind of set your sights where things will be going.
[13:26.680 --> 13:29.600]  But it is more currently more popular with companies.
[13:29.600 --> 13:32.700]  So like your IT department can get you the YubiKey right now.
[13:32.700 --> 13:34.680]  It can hand you the physical token.
[13:34.980 --> 13:37.500]  So that's something where you might also be seeing this.
[13:37.500 --> 13:42.800]  But a lot of these factors we're kind of focusing on as a consumer application channel.
[13:44.280 --> 13:49.580]  But I did want to back up these kind of qualitative examples with some more quantitative data.
[13:49.580 --> 13:53.980]  And to do that, I wanted to think about more granularly how we're measuring the effectiveness of 2FA.
[13:53.980 --> 13:59.300]  And so separating this into three categories, kind of thinking about this in the life cycle of 2FA.
[13:59.300 --> 14:03.300]  So there is this onboarding consideration, right, that I've mentioned a couple of times already.
[14:03.300 --> 14:11.800]  There's also a user experience, ongoing user experience for how you're going to work with these different channels as you're using them on an ongoing basis.
[14:11.800 --> 14:17.320]  And then also the account recovery side of things, like what happens when you lose one of these factors?
[14:17.320 --> 14:18.840]  What do you do at that point?
[14:18.840 --> 14:21.340]  Is there a path to recovery there?
[14:22.580 --> 14:25.720]  And so the research that I'm talking about is from Brigham Young University.
[14:25.720 --> 14:28.480]  It was presented at the Supes conference last August.
[14:28.800 --> 14:31.800]  And so it was a study focused on setting up five factors.
[14:31.800 --> 14:34.920]  And so the factors that they talked about are the ones that we kind of already walked through,
[14:34.920 --> 14:41.500]  which were SMS, TOTP, pre-generated codes, push authentication, and U2F security keys.
[14:41.500 --> 14:50.020]  So a couple of important caveats is the study didn't take into account how to store pre-generated codes.
[14:50.360 --> 14:55.120]  And so that's something that I think is pretty important for this type of channel.
[14:55.220 --> 14:59.640]  But 25% of participants noted that the pre-generated codes just didn't feel secure.
[14:59.640 --> 15:03.120]  But when it comes to factor setup, this is the winner from the study.
[15:03.540 --> 15:07.540]  But like I said, the code storage wasn't considered for timing.
[15:07.540 --> 15:11.460]  So I don't know exactly what that would be like on an ongoing basis.
[15:11.880 --> 15:15.580]  From a different study in 2018 that focused just on Yubikeys,
[15:15.580 --> 15:21.360]  I think this study is really interesting because the success varied a lot depending on the platform that they were setting it up on.
[15:21.360 --> 15:27.060]  Even though the channel, the thing that they were using to set up the U2F was always a Yubikey.
[15:27.060 --> 15:30.900]  It was always the same Yubikey that they were using across channels.
[15:30.900 --> 15:37.320]  So 83% of people were successful on Google, where only 32% of people were successful on Facebook.
[15:37.320 --> 15:41.940]  And if you've been following U2F and WebAuthn, you know a lot has changed since 2018.
[15:42.040 --> 15:48.360]  But I do think this is a really interesting look at how onboarding user experience impacts user success.
[15:48.360 --> 15:52.160]  And so you can guide people towards a successful solution here.
[15:52.300 --> 15:58.900]  But you don't want to guide people in a way like Microsoft Authenticator or Windows Logon Authorization Tool did,
[15:58.900 --> 16:06.540]  where more people locked themselves out of their computer than were able to successfully set it up for that particular platform.
[16:07.560 --> 16:13.200]  So moving on to usability, one measure of usability was the amount of time that it took to authenticate.
[16:13.200 --> 16:17.080]  And in that metric, U2F and Push were the winners there.
[16:17.080 --> 16:19.960]  So they have the fastest median authentication times.
[16:19.960 --> 16:26.240]  So compared to SMS, some Duo research from last year said that this can save people 13 to 18 minutes annually
[16:26.240 --> 16:31.220]  in terms of ongoing authentications, if time is something that you're concerned about.
[16:31.220 --> 16:33.620]  And this is a measure of usability ongoing.
[16:33.620 --> 16:41.600]  But the system usability scale, or SUS, this is something that's a standard measurement used by researchers for this type of thing.
[16:41.720 --> 16:47.200]  So actually all of the methods had a pretty good usability score, but TOTP came out on top.
[16:47.200 --> 16:49.940]  Again, this is like ignoring just passwords.
[16:49.940 --> 16:57.520]  So turns out people don't like adding a second factor to a lot of their authentication, because that's additional friction.
[16:57.520 --> 17:02.440]  But if you're going to be using a second factor, then TOTP was what they considered most usable.
[17:02.440 --> 17:07.720]  And this actually surprised me, because this was the same study that said that two-thirds of users had issues with the timeout,
[17:07.720 --> 17:12.320]  but that didn't affect their rating here, so maybe that's something that we don't need to be as concerned about.
[17:13.240 --> 17:16.900]  I do want to point out that there was somewhat of an inverse relationship here,
[17:16.900 --> 17:20.940]  because U2F and Push had some of the lower usability scores,
[17:20.940 --> 17:27.420]  so the researchers observed that faster authentication does not necessarily mean higher usability.
[17:28.560 --> 17:33.740]  So this is something that we were looking at, and you might notice that SMS does not come out on top on any of these.
[17:33.740 --> 17:39.200]  People didn't really like it as a factor. It was one of the lower factors for the authentication score.
[17:39.200 --> 17:43.900]  But I do think that even though there's a lot of tradeoffs to the level of security in these options,
[17:43.900 --> 17:49.000]  it's important to note that SMS-based 2FA is still better than no 2FA at all.
[17:49.000 --> 17:52.800]  And this is really easy for me to say, like, you know, I work for a company that does this,
[17:52.800 --> 17:55.500]  but there's research here to back me up.
[17:55.500 --> 18:01.160]  So a 2019 Google study found that an SMS code sent to a recovery phone number
[18:01.160 --> 18:09.280]  helped block 100% of automated bots, 96% of bulk phishing attacks, and 76% of targeted attacks.
[18:09.280 --> 18:13.220]  So it's still really good coverage, especially for something that's really easy to set up
[18:13.220 --> 18:18.320]  that might have high likelihood that users are actually going to turn on a second factor.
[18:18.760 --> 18:23.540]  But when you start looking at push authentication, there is increased protection.
[18:23.540 --> 18:32.560]  So this gets bulk phishing attack protection up to 99%, and it has a 90% effectiveness for targeted attacks as well.
[18:32.560 --> 18:38.920]  So you have different options for 2FA, but you also do need to get your users to enable the extra security.
[18:39.440 --> 18:43.800]  And adoption of 2FA is pretty abysmal. There's a few reasons for that.
[18:44.400 --> 18:47.520]  This is especially abysmal for opt-in 2FA.
[18:47.520 --> 18:58.840]  Last month, DHH on Twitter, who works for Basecamp, I think, and is behind the new email platform, Hey,
[18:58.840 --> 19:05.880]  was asking about how the opt-in rate for different companies was for consumer 2FA.
[19:06.160 --> 19:10.700]  And companies willing to share this data say that it's usually somewhere between 1% and 2%.
[19:10.700 --> 19:15.760]  Depending on the type of platform, depending on how you're getting users to turn it on,
[19:15.760 --> 19:21.580]  you probably are going to have a pretty low rate of adoption here.
[19:21.580 --> 19:24.760]  So he mentions that Basecamp was at a paltry 1%.
[19:25.920 --> 19:31.380]  And one of the observations behind this is that there is technology like this.
[19:31.380 --> 19:38.580]  Technology is available to help mitigate the risk and improve the consumer experience, but it often goes unused.
[19:38.580 --> 19:49.760]  And so I think this is one of the things that we as security professionals and people that have the ability to encourage people to opt into these more secure measures,
[19:49.760 --> 19:55.180]  need to be considering how we can push people in that direction without increasing too much paranoia.
[19:55.800 --> 20:05.780]  So in terms of 2FA adoption, a 2019 BYU study found that people were willing to add 2FA to their accounts if they saw the value in the account.
[20:05.780 --> 20:11.000]  But 13% of participants just thought that the inconvenience was too high, no matter what.
[20:11.460 --> 20:14.780]  And that's because a lot of people just believe they're not a target.
[20:14.920 --> 20:19.700]  And so this research participant said, I just don't think I have anything that people would want to take from me.
[20:19.700 --> 20:22.620]  So I think that's why I haven't been very worried about it.
[20:22.620 --> 20:24.860]  And you can see this with a lot of people in your own life.
[20:24.860 --> 20:28.460]  They don't understand the risk that's associated with all of their accounts.
[20:28.540 --> 20:35.140]  And maybe that's okay. Maybe you don't need to be adding two-factor authentication to the pizza delivery app that you're using.
[20:35.140 --> 20:48.420]  But how do we encourage people to add stronger authentication methods beyond passwords to things like their emails and like their bank accounts and other places where that level of paranoia is perhaps justified?
[20:49.240 --> 20:54.420]  So hope is not lost here. Awareness and adoption have almost doubled in the last two years.
[20:54.420 --> 20:58.500]  There's reasons for this. Bitcoin has spiked a couple of times within there.
[20:58.500 --> 21:02.080]  But there's other things that we might be able to attribute this to.
[21:02.080 --> 21:06.500]  And so one of these is how we drive adoption of multi-factor authentication.
[21:06.500 --> 21:11.440]  And websites are getting more savvy about how they're getting people to turn on 2FA.
[21:11.720 --> 21:17.720]  But unless you're somebody like Coinbase, you're probably not going to make two-factor authentication mandatory.
[21:17.980 --> 21:24.040]  But you do have other options than just hiding it in profile settings where people aren't going to think to go get it.
[21:24.040 --> 21:26.540]  And so you can prompt people when they log in.
[21:26.540 --> 21:28.480]  You can offer product incentives.
[21:28.480 --> 21:36.780]  You can have a really annoying and persistent login prompt that is telling people they need to turn on additional factors for authentication every time they log in.
[21:36.780 --> 21:42.040]  The more annoying you are about it, the more likely that people are going to be to turn it on.
[21:42.040 --> 21:46.460]  But that's also going to increase the friction and you don't want to annoy your customers too much.
[21:46.900 --> 21:53.500]  So we do know that strategies like product incentives work from looking at the Google Trends for 2FA searches.
[21:53.500 --> 22:00.980]  So if you can guess what the spike in August 2018 was, it's only gone up from there.
[22:00.980 --> 22:04.820]  But it was pretty flat for many, many years leading up to that.
[22:04.820 --> 22:11.600]  That was when Fortnite decided to offer in-game incentives for its users to turn on two-factor authentication.
[22:11.640 --> 22:16.340]  And so if you're not familiar with Fortnite, it's an incredibly popular video game.
[22:16.360 --> 22:21.880]  And video games are some of the people that have gotten most creative with the incentives that they're offering people.
[22:21.880 --> 22:27.960]  One, because there's in-game trading that has real monetary consequences to their users.
[22:27.960 --> 22:32.560]  But two, because some of the incentives that they can offer don't actually cost them a lot of money.
[22:33.460 --> 22:39.440]  And so now even two years later, three of the top five related search queries to 2FA have to do with Fortnite.
[22:39.440 --> 22:46.520]  Three of the top five related topics to 2FA have to do with video games. Epic Games is the company that owns Fortnite.
[22:46.640 --> 22:49.800]  But they aren't the only ones that are offering incentives.
[22:49.800 --> 22:55.120]  Lots of gaming companies are offering incentives around that. You can see lots of examples there.
[22:55.120 --> 22:58.240]  But there's other companies that are offering product incentives as well.
[22:58.240 --> 23:05.240]  So a good example of this is MailChimp will offer you a 10% discount for three months for users that turn on 2FA.
[23:05.620 --> 23:11.800]  And so you can understand kind of the trade-off here of what it would be valuable to your company.
[23:11.800 --> 23:17.100]  Like, what is the account takeover risk? What is the loss that you're experiencing from something like this?
[23:17.100 --> 23:25.460]  And does it make sense for you to offer some product incentives or discounts to your customers that might get them to opt into additional security?
[23:27.320 --> 23:32.580]  And so like anything, you want to make sure that you're going to measure how effective this was.
[23:33.020 --> 23:37.080]  So ideally you would be setting these measures before you embark on this kind of journey.
[23:37.080 --> 23:44.140]  But some of the things that I encourage people to think about as they're measuring the effectiveness of their authentication strategies,
[23:44.140 --> 23:48.700]  like this is going to depend on your business, but here are some of the options that you might have.
[23:48.700 --> 23:53.740]  Just total losses due to account takeover. You probably want to see that number go down.
[23:53.940 --> 23:58.020]  You might want to care about the total number of compromised accounts too.
[23:58.560 --> 24:02.740]  Decreasing the number of customers that are actually having their accounts taken over.
[24:02.960 --> 24:08.700]  One thing that I do think is really important to look at is just the support costs related to the losses.
[24:08.800 --> 24:14.120]  So if you're somebody that's starting to require or encourage a lot more two-factor authentication,
[24:14.120 --> 24:17.980]  there are going to be additional support hurdles that you're going to come across.
[24:17.980 --> 24:23.860]  So especially when it comes to the account recovery side of things, people are going to get locked out of their accounts more often.
[24:23.860 --> 24:27.620]  And you want to have a smooth path. Hopefully self-service.
[24:27.620 --> 24:35.900]  Hopefully you've enabled three or four factors so that they can gain access to their accounts again if they lose access to any one of their factors.
[24:35.900 --> 24:45.200]  But you want to make sure that you've also equipped support with the tools to make sure that they can securely and safely get people back into their accounts.
[24:45.500 --> 24:50.700]  Even if this is going to take more time on the support team, it might be worth it overall.
[24:50.700 --> 24:55.740]  And finally, you just want to make sure that user satisfaction is at least staying the same if not going up.
[24:55.740 --> 25:01.580]  If you're doing something like having really persistent login prompts for turning on 2FA,
[25:01.580 --> 25:06.380]  you might want to make sure that you're not annoying your customers too much overall.
[25:07.480 --> 25:10.900]  So there's definitely no one-size-fits-all solution here.
[25:10.900 --> 25:14.580]  But the advice that I end up giving a lot of folks boils down to something like this,
[25:14.580 --> 25:17.440]  which is to delight your most security-conscious users.
[25:17.440 --> 25:25.060]  You don't want people that are paranoid with good reason, have higher security needs and concerns,
[25:25.060 --> 25:28.000]  to be upset at the lack of options that you're providing.
[25:28.000 --> 25:30.300]  But you do want to provide options for the rest.
[25:30.300 --> 25:38.320]  You don't necessarily need to force everybody on your consumer website to have TOTP or YubiKey or anything like that.
[25:38.320 --> 25:44.740]  But you want to make sure that it's usable for people, depending on the risk that they're willing to accept.
[25:45.240 --> 25:53.800]  Because, like the security researcher Cormac Hurley says, when we exaggerate all dangers, we simply train users to ignore us.
[25:53.820 --> 25:58.760]  So I hope I've given you some inspiration for how to think about your authentication systems.
[25:58.760 --> 26:04.360]  I'll be around. You can find me on Discord, you can find me on Twitter if you have any questions.
[26:04.360 --> 26:08.700]  Once again, my name is Kelly Robinson, and thank you for listening.
